Syslog, CDR and Debug Parameters

Determines whether the device sends logs and error messages (e.g., CDRs) generated by the device to a Syslog server.

Note:

Defines the IP address (in dotted-decimal notation) or FQDN of the computer on which the Syslog server is running. The Syslog server is an application designed to collect the logs and error messages generated by the device.

The default IP address is 0.0.0.0.

Defines the UDP port of the Syslog server.

The valid range is 0 to 65,535. The default port is 514.

Defines the transport protocol for communicating with the primary Syslog server.

Note: If you configure the parameter to TLS, you also need to select a TLS Context (certificate), as described in Configuring the Primary Syslog Server Address.

Assigns a TLS Context when the TLS transport protocol is used for communication with the Syslog server.

For configuring TLS Contexts, see Configuring TLS Certificate Contexts.

To configure the transport protocol for the primary syslog server, use the [SyslogProtocol] parameter. To configure the transport protocol for secondary syslog servers, use the Syslog Servers table (see Configuring Secondary Syslog Servers.

Note: Only the root certificate of the selected TLS Context is used (and not the other TLS Context parameters such as 'TLS Version').

Enables DNS-resolution into IPv6 addresses. If disabled, only enables DNS-resolution into IPv4 addresses.

Defines the minimum severity level of messages included in the Syslog message that is generated by the device. The specified severity level and all higher severity levels are included in the Syslog message. For example, if you configure the parameter to Alert, the Syslog will include messages with Alert severity level and messages with Fatal severity level. The severity levels are listed below from highest to lowest.

Note: It's strongly recommended to leave the Syslog severity level at its default setting. Changing severity level is typically done only by AudioCodes Support for debugging.

Enables the device to send the Syslog messages to the serial console (over the device's physical serial interface). This may be useful, for example, if you no longer have network access to the device and you would like to perform diagnostics.

Note:

Defines the destination address (IP address or FQDN) to where CDR logs are sent.

The default value is a null string, which causes CDR messages to be sent with all Syslog messages to the Syslog server.

Note:

Defines SIP release cause codes that if received for the call, the devicedoes not sent Call-End CDRs for the call.

The valid value is 300 through to 699. You can configure the parameter with multiple codes using a comma to separate them (e.g., 301,400,404). You can also use "xx" to denote a range (e.g., 3xx).

Enables the device to not send Call-End CDRs if the call's duration is zero (0).

Enables media and signaling-related CDRs to be sent to a Syslog server and defines the call stage at which they are sent.

Note:

Enables media-related CDRs of SBC calls to be sent to a Syslog server and defines the call stage at which they are sent.

Note:

Enables signaling-related CDRs to be sent to a REST server and defines the call stage at which they are sent.

Note:

Defines the REST server (by name as configured in the Remote Web Services table) to where the device sends CDRs through REST API.

The valid value is a string (i.e., name of the REST server). By default, no value is defined.

Note:

Enables the device to hide the values of the Caller and Callee fields in CDRs of certain report outputs.

For more information, see Hiding Caller and Callee CDR Field Values.

Defines the SIP response code that you want the device to consider as call success, which is indicated by the optional 'Call Success' field in the sent CDR. This parameter overrides the device's default behavior of how it considers calls a success or failure based on SIP responses.

The valid value is string of up to 128 characters to represent SIP response codes (e.g., 404). You can configure the parameter with multiple response codes, whereby each code is separated by a comma without spaces before or after (e.g., 404,408,406). You can also configure a range of responses using the "xx" wildcard (e.g., 4xx,502). By default, no value is defined.

Note: If an overlap of a SIP response occurs between the configured 'Call Success SIP Reasons' and 'Call Failure SIP Reasons' parameters, the device uses the parameter that is configured with the specific response code, instead of the parameter configured with the range ("xx"). For example, if you configure the 'Call Success SIP Reasons' parameter with "404,5xx" and the 'Call Failure SIP Reasons' parameter with "502", for 502 responses, the device uses the settings of the 'Call Failure SIP Reasons' parameter only. In other words, a call with SIP response code 502 is considered as a call failure.

Defines the SIP response codes that you want the device to consider as call failure, which is indicated by the optional 'Call Success' field in the sent CDR. This parameter overrides the device's default behavior of how it considers calls a success or failure based on SIP responses.

The valid value is string of up to 128 characters to represent SIP response codes (e.g., 486). You can configure the parameter with multiple response codes, whereby each code is separated by a comma without spaces before or after (e.g., 486,408,406). You can also configure a range of responses using the "xx" wildcard (e.g., 4xx,502). By default, no value is defined.

Note: If an overlap of a SIP response occurs between the configured 'Call Success SIP Reasons' and 'Call Failure SIP Reasons' parameters, the device uses the parameter that is configured with the specific response code, instead of the parameter configured with the range ("xx"). For example, if you configure the 'Call Success SIP Reasons' parameter with "486,5xx" and the 'Call Failure SIP Reasons' parameter with "502", for 502 responses, the device uses the settings of the 'Call Failure SIP Reasons' parameter only. In other words, a call with SIP response code 502 is considered as a call failure.

Defines the internal response codes (generated by the device) that you want the device to consider as call success, which is indicated by the optional 'Call Success' field in the sent CDR. This parameter overrides the device's default behavior of how it considers calls a success or failure based on internally responses.

The valid value is string of up to 128 characters to represent internal response codes (e.g., 851). You can configure the parameter with multiple response codes, whereby each code is separated by a comma without spaces before or after (e.g., 851,320). You can also configure a range of responses using the "xx" wildcard (e.g., 8xx,320). By default, no value is defined.

Note:

Defines the internal response codes (generated by the device) that you want the device to consider as call failure, which is indicated by the optional 'Call Success' field in the sent CDR. This parameter overrides the device's default behavior of how it considers calls a success or failure based on internally responses.

The valid value is string of up to 128 characters to represent internal response codes (e.g., 851). You can configure the parameter with multiple response codes, whereby each code is separated by a comma without spaces before or after (e.g., 851,320). You can also configure a range of responses using the "xx" wildcard (e.g., 8xx,320). By default, no value is defined.

Note:

Defines if the device considers a call as a success or failure when the internal response (generated by the device) "GWAPP_NO_USER_RESPONDING" (18) is received before call connect (SIP 200 OK).

Defines if the device considers a call as a success or failure when the internal response (generated by the device) "GWAPP_NO_USER_RESPONDING" (18) is received after call connect (SIP 200 OK).

Defines if the device considers a call as a success or failure when the internal response (generated by the device) "RELEASE_BECAUSE_CALL_TRANSFERRED" (807) is generated before call connect (SIP 200 OK).

Defines if the device considers a call as a success or failure when the internal response (generated by the device) "RELEASE_BECAUSE_CALL_TRANSFERRED" (807) is generated after call connect (SIP 200 OK).

Defines the size (in kilobytes) of each locally stored CDR file. When the Current file reaches this size, the device creates a CDR file containing all the CDRs from the Current file.

The valid value is 100 to 10,000. The default is 1024.

Note:

Defines the maximum number of locally stored CDR files. If the maximum number is reached and a new file is created, the oldest file is deleted to make space for the new file (i.e., FIFO).

The valid value is 2 to 4096 . The default is 5.

Note: The parameter is applicable only to local storage of CDRs.

Defines how often (in minutes) the device creates a new CDR file for locally stored CDRs. For example, if configured to 60, every hour it creates a CDR file containing all the CDRs from the Current file.

The valid value is 2 to 1440. The default is 60.

Note:

Enables Syslog debug reporting and logging level.

Enables creation of CDR messages for non-call SIP dialogs (such as SUBSCRIBE, OPTIONS, and REGISTER).

Note: The parameter is applicable only to the SBC application.

Enables the device to accumulate and bundle multiple debug messages into a single UDP packet and then send it to a Syslog server. The benefit of this feature is that it reduces the number of UDP Syslog packets, thereby improving (optimizing) CPU utilization.

Note: The size of the bundled message is configured by the MaxBundleSyslogLength parameter.

Defines the maximum size (in bytes) threshold of logged Syslog messages bundled into a single UDP packet, after which they are sent to a Syslog server.

The valid value range is 0 to 1220 (where 0 indicates that no bundling occurs). The default is 1220.

Note: The parameter is applicable only if the [GWDebugLevel] parameter is enabled.

Enables the protection of the device's CPU resources during debug reporting, ensuring voice traffic is unaffected. If CPU resources drop (i.e., high CPU usage) to a critical level (threshold), the device automatically lowers the debug level to free up CPU resources that were required for the previous debug-level functionality. When sufficient CPU resources become available again, the device increases the debug level. The threshold is configured by the 'Debug Level High Threshold' parameter (see below).

Defines the threshold (in percentage) for automatically switching to a different debug level, depending on CPU usage. The parameter is applicable only if the 'Syslog CPU Protection' parameter is enabled.

The valid value is 0 to 100. The default is 90.

The debug level is changed upon the following scenarios:

For example, assume that the threshold is set to 70% and the Debug Level to Detailed (5). When CPU usage reaches 70%, the debug level is reduced to Basic (1). When CPU usage increases by 5% or more than the threshold (i.e., greater than 75%), the debug level is disabled - No Debug (0). When the CPU usage decreases to 5% less than the threshold (e.g., 65%), the debug level is increased to Basic (1). When the CPU usage decreases to 20% less than the threshold (e.g., 50%), the debug level changes to Detailed (5).

Note: The device does not increase the debug level to a level that is higher than what you configured for the 'Debug Level' parameter.

Defines the time zone that is displayed with the timestamp in CDRs. The timestamp appears in the CDR fields "Setup Time", "Connect Time", and "Release Time".

The valid value is a string of up to six characters. The default is UTC. For example, if you configure the parameter TimeZoneFormat = GMT+11, the timestamp in CDRs are generated with the following time zone display:

17:47:45.411 GMT+11 Sun Jan 03 2018

Note: The time zone is only for display purposes; it does not configure the actual time zone.

Defines the unit of measurement for call duration ("Duration" field) in CDRs generated by the device.

The parameter applies to CDRs for Syslog, RADIUS, local-device storage, and CDR history displayed in the Web interface.

Enables or disables the inclusion of the sequence number (S=) in CDR Syslog messages.

Enables the use of the Global Session ID in SIP messages (AC-Session-ID header), which is a unique identifier of the call session, even if it traverses multiple devices.

For more information, see Enabling Same Call Session ID over Multiple Devices.

Defines the operations (activities) performed in the Web interface that are reported to a Syslog server.

Note: For the ini file parameter, enclose values in single quotation marks, for example: ActivityListToLog = 'pvc', 'afl', 'dr', 'fb', 'swu', 'naa', 'spc'.

Enables the monitoring, through Syslog messages, of parameters that are modified on-the-fly.

Defines the network interface from where the device sends Syslog messages to a Syslog server.

Enables ISDN traces of Facility Information Elements (IE) for ISDN call diagnostics. This allows you to trace all the parameters contained in the Facility IE and view them in the Syslog.

Note:

Defines the IP address (IPv4 or IPv6) of the server for capturing debug recording.

For more information, see Configuring the Debug Recording Server Address.

Defines the UDP port of the server for capturing debug recording. The default is 925.

Defines the IP Interface through which the device sends captured traffic to the debug server. For more information, see Configuring the Debug Recording Server Address.

Enables the automatic generation of a Core Dump file upon a device crash.

Note: For the parameter to take effect, a device reset is required.

Defines the IP address of the remote server where you want the device to send the Core Dump file.

By default, no IP address is defined.

Enables the device to send SIP call messages to OVOC so that OVOC can display SIP call dialog sessions as SIP call flow diagrams.

For more information, see Enabling SIP Call Flow Diagrams in OVOC.

Defines the size (in Kbytes) of the system log file.

The valid value range is 10 to 2000 KB. The default is 200 KB.

To view the logged information in this file, use the CLI command show system log.